Ten artykuł jest próbą wyjaśnienia podstaw sposobu rozwijania dystrybucji systemów linuksowych.

Jako że PLD jest dystrybucją bazującą na systemie paczek RPM, następująca wiedza jest niezbędna, aby kontynuować dalszą naukę:

• Podstawowe operacje rpm
• Korzystanie z systemów kontroli wersji takich jak git czy svn
• Obsługa różnic między plikami w oparciu o diff i patch
• Kompilowanie oprogramowania ze źródeł

W porównaniu do innych dużych dystrybucji, PLD Linux nie ma komercyjnego wsparcia. Społeczność deweloperów składa się z ludzi, którzy po prostu potrzebują wykonać jakąś pracę, albo czerpią przyjemność z uczestniczenia w tym, otwartym projekcie (często oba powody są równie istotne).

W swoich wewnętrznych strukturach PLD jest podzielone na niezależne linie dystrybucyjne, dla każdej z wersji PLD. Każdą linią zarządza osoba zwana kierownikiem wydania (Release Manager). RM zajmuje się utrzymywaniem części infrastruktury PLD, podejmowaniem decyzji, w momencie kiedy deweloperzy sami nie mogą rozstrzygnąć jakiejś kwestii i opiekowaniem się zawartością serwera FTP.

Inaczej niż RM, większość deweloperów zajmuje się głównie utrzymywaniem pakietów, co zazwyczaj oznacza pracę z plikami spec (będą one wyjaśnione później). Nie ma tutaj wymuszonej odpowiedzialności i każdy może działać z jakimkolwiek pakietem. Jedyną zasadą jest dotykaj się czegoś, tylko wtedy gdy, jesteś pewien, że wiesz co robisz. Innymi słowy ludzie nie wybierają pakietów do pracy losowo, ale zajmują się tymi, których potrzebują. Może to wyglądać trochę chaotycznie, ale ten model jest całkiem stabilny, ponieważ każda zmiana jest niemal natychmiast weryfikowana. Nie trzeba chyba zaznaczać, że deweloperzy przepadają za takim sposobem organizacji, bo nie potrzebują niczyjej zgody, aby wprowadzać zmiany, których potrzebują.

Plik spec zawiera metadane i instrukcje budowania wymagane do stworzenia przynajmniej jednego pakietu RPM. Jest to plik tekstowy przeznaczony do pracy skryptu builder, który z kolei obsługuje cały proces, od skompletowania wszystkich niezbędnych źródeł z infrastruktury PLD (lub bezpośrednio z Internetu), do pakowania wyników w instalowalny plik RPM (druga część jest wykonywana przez narzędzie rpmbuild).

Pliki spec rezydują w podkatalogach poszczególnych pakietów wewnątrz katalogu packages naszego serwera git.

Distfiles to serwer FTP/HTTP, służący do przechowywania plików binarnych, np. spakowanych źródeł programów. Dokonując zmiany w SPECU, automat pobiera plik, wskazany w polu SourceX pliku spec, następnie umieszcza go na serwerze. Dzięki temu budowane pakiety będą pobierane zawsze z tego serwera. Archiwa ze źródłami, których nie obsłuży ten automat - np. źródła pobrane z systemu kontroli wersji, muszą być umieszczane osobiście przez dewelopera przy każdej ich zmianie. Więcej o distfiles.

Łatki źródeł programów (trzymanych w distfiles), init-skrypty i źródła innych plików koniecznych do budowania pakietów, są przechowywane w git w katalogu pakietu.

Skrypt builder jest odpowiedzialny za cały proces montowania pakietu. Zbiera wszystkie potrzebne źródła, sprawdza wymagane zależności, rozpakowuje źródła, kompiluje je i na końcu pakuje rezultaty w instalowalny plik RPM.

Skrypt ten może zostać uruchomiony przez użytkownika w specjalnej strukturze katalogów w katalogu domowym użytkownika i w znacznym stopniu jest zależny od programu rpmbuild dostarczanego przez pakiet rpm-build.

Ten sam skrypt jest używany przez maszyny stanowiące infrastrukturę PLD do budowania pakietów, umieszczanych później na serwerze FTP.

Skrypt adapter jest narzędziem mającym pomóc deweloperowi w procesie tworzenia czystych plików spec. Wykonuje on automatycznie szereg czynności czyszczących i zajmuje się częstymi błędami pojawiającymi się w plikach spec.

PLD jest bardzo restrykcyjne jeżeli chodzi o pliki spec, więc zaleca się aby korzystać ze skryptu adaptującego w przypadku każdego pliku wysyłanego na listę mailingową deweloperów czy dodawanych do repozytorium.

Możesz także poczytać więcej o skrypcie adaptującym.

Cały proces tworzenia pakietów odbywa się dzięki klasterowi maszyn budujących pliki RPM z odpowiadających im plików spec. Każda jednostka ma swoje przeznaczenie. Niektóre budują pakiety na konkretne architektury, a inne tworzą pakiety src.rpm zawierające wszystko co jest potrzebne do budowy danego pakietu. Są też węzły służące deweloperom jako środowisko testowe do budowania i sprawdzania pakietów.

Możesz także poczytać więcej o komputerach PLD.

Każda linia dystrybucji ma swój własny zestaw narzędzi do tworzenia pakietów, i własną kolejkę budowania zarządzaną przez grupę zaufanych deweloperów.

Zasady wysyłania żądań do budowania pakietów PLD 3.0 (Th) .

Zasady wysyłania żądań do budowania pakietów PLD 2.0 (Ac) .

Kolejka builderów PLD 3.0 (Th).

Powinieneś zacząć od zapisania się na przynajmniej jedną z naszych list mailingowych. Zwłaszcza na pld-devel-en (lub pl dla polskich deweloperów), a także na pld-discuss przeznaczoną na różne dyskusje związane z dystrybucją.

Zauważ, że istnieje także specjalna lista pld-cvs-commit, która nie jest przeznaczona do dyskusji. Zbiera ona natomiast informacje o wszystkich zmianach wprowadzanych przez innych deweloperów na stronie www, czy w repozytoriach git, CVS i SVN.

Zobacz przygotowanie środowiska pracy.

Zacznij od prostych rzeczy. Wybranie losowego pakietu i aktualizowanie go, może wydawać się dobrym pomysłem, ale w ten sposób prędzej sprowadzisz na siebie kłopoty. Zepsucie aplikacji, od której zależą inne pakiety, nie zaszkodzi dystrybucji samej w sobie, ale zdenerwuje ludzi i utrudni ci dalszą pracę. Spróbuj dodać plik spec dla małej aplikacji, której używasz każdego dnia, albo zaktualizuj istniejący spec pod nowe wydanie jakiegoś użytecznego narzędzia, bez którego nie możesz żyć.

Zanim stwierdzisz, że jesteś gotowy opublikować swój spec, dwa razy sprawdź sekcję zależności i upewnij się, że pakiet buduje się czysto (na przykład po stworzeniu pliku RPM nie zostają żadne pliki - builder informuje o tym na końcu procesu).

Jeżeli się nudzisz i nie wiesz co mógłbyś zrobić, możesz spróbować zająć się listą PLD-doc/PLD-specs-TODO (Ta sama lista na wiki, z dodatkowymi wpisami http://pld-users.org/specs-todo), albo PLD-doc/PLD-update-TODO. Poza tym jest lista z generowanymi automatycznie nagłówkami TODO z *.spec: PLD-doc/specs-auto-todo.txt.

Jako początkujący deweloper nie będziesz miał dostępu odczytu/zapisu do repozytorium git, więc będziesz musiał znaleźć kogoś kto sprawdzi twoje zmiany i doda je do repozytorium. Najlepszym wyjściem jest wysłanie maila na listę pld-devel-en (lub pl) i dołączenie do niego unified diff twoich zmian zamiast oryginalnych plików (czy wręcz całych, jeżeli jakieś dodajesz) wraz z krótkim opisem tego co zrobiłeś.

Jak tylko jakiś deweloper będzie miał czas przyjrzeć się twoim zmianom, zostaniesz poinformowany o ewentualnych błędach wymagających poprawek i w końcu twoje pliki zostaną opublikowane.

Kiedy twoje zmiany okażą się szczególnie cenne, inni deweloperzy mogą zdecydować się przyznać ci pełne prawa dostępu do naszego repozytorium. Ten proces jest zawsze inicjowany przez kogoś kto ma już prawa odczytu/zapisu. Wysyłanie próśb o ten dostęp nie będzie mile widziane.

Mając już prawa odczytu/zapisu, będziesz mógł regularnie aktualizować repozytoria na serwerze git. Pamiętaj o sprawdzeniu plików, które dodajesz przez wysłaniem ich do repozytorium. Upewnij się także, że udostępniasz zrozumiały zapis zmian (commitlog). Zapis ten powinien mieć taki format:

- pierwsza zmiana 
- druga zmiana
- trzecia zmiana
- jakieś dodatkowe informacje

Nawet jeżeli w twoim commitlog jest tylko jedna wiadomość, poprzedzenie jej myślnikiem poprawi czytelność.

Po commicie pliku spec, konieczne jest zbudowanie pakietu. Cały proces wygląda następująco:

1. Plik spec jest commitowany (włączając zmiany w wymaganych łatach i innych plikach związanych z plikiem spec)
2. Jeden z deweloperów wysyła zlecenie na testowe zbudowanie pakietu (za pomocą skryptu make-request.sh). Jeśli nie masz takich uprawnień, skontaktuj się w tej sprawie z RM-em. Istnieje możliwość pominięcia tego kroku i poproszenie o zbudowanie pakietu do tzw. upgrade, jednak nie jest to zalecane, gdyż upgrade pakietów na części builderów spowoduje rozsynchronizowanie oprogramowania. Na winnym takiego stanu będzie wykonana publiczna egzekucja.
3. Pakiet jest buduje się prawidłowo na wszystkich architekturach.
4. Jeden z uprzywilejowanych deweloperów wysyła zlecenie budowania aktualizującego (ten sam skrypt co powyżej) - skontaktuj się z RM-em w sprawie dostępu.
5. Pakiet jest budowany ponownie i aktualizowany na wszystkich builderach.
6. Pakiet jest zapisywany w kolejce (ready dla Ac i test dla Th).
7. Od tej pory pakietem zajmuje się tylko RM. Decyduje, kiedy pakiet jest gotowy do przeniesienia do stabilnego drzewa (lub do updates jeśli jest to wydana wersja PLD). Jeśli sądzisz, że trwa to za długo, sprawdź czy zależności (zarówno nowo wprowadzone jak i ewentualnie popsute przez jakieś pakiety) w kolejce są spełnione.
8. W końcu pakiet jest przenoszony do stabilnej gałęzi lub do updates i od tej pory każdy może ten pakiet używać.
9. Pakiet trafia do obsolete jeśli jest przygotowana nowsza wersja pakietu.

• - Fixing --as-needed problems